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5 PROCEDE POUR LA SECURISATION PES SYSTEMES INFORMATIOUES 
INCORPORANT UN MODULE D'INTERPRETATION PE CODE , 



10 La presente invention concerne la securisation des systemes informatiques 
comportant au moins un module d' interpretation de code et des capacit6s 
memoire de stockage du code a interpreter. 

Elle a plus particulidrement pour objet de resoudre les probldmes de 
15 securisation des systemes informatiques comportant au moins un module 
^interpretation de code (un code etant defini comme un ensemble structure 
^instructions) qu'on appellera simplement "interpreteur" par la suite 
(interpreteur materiel : micro-contrdleur, micro-processeur ou logiciel : 
machine virtuelle) et des capacit6s memoire de stockage du code a interpreter 
20 (ou "code interprete"). 

Ledit code peut etre ecrit directement par un programmeur, etre obtenu de 
mani^re automatique (ce qu'on appellera la "generation de code") a partir d ! un 
"code source" dans un langage qui est g6n6ralement de plus haut niveau ou 
25 encore resulter d'une combinaison de production automatique et 
^interventions manuelles. 

D'une fa?on gen6rale, on sait que la plupart des attaques recensees contre de 
tels systemes informatiques reposent sur des mesures physiques (Emission 
30 electromagn6tique, etc.) lors de l'execution et necessitent la synchronisation 
avec le code interprete. En d'autres termes, il est necessaire k Tintrus de 



wo imiimuiiMm pct/fr2003/003805 

determiner k quel moment Tinterpreteur se trouve en train d'executer certaines 
fonctionnalites du code. Parmi ces techniques les plus connues, on peut citer 
celles developp6es pour retrouver une cl6 dans des algorithmes 
cryptographiques par espionnage passif de remission physique dun circuit : 

5 les attaques de type SPA ("Simple Power Analysis") et DPA ("Differential 
Power Analysis") en particulier ont 6t€ utilises avec succes pour d6couvrir 
des cl6s DES ("Data Encryption Standard"). A titre d'exemple, sur une plate- 
forme Java embarquee ("Java Card", "JEFF", "J2ME", ... ), ces attaques 
peuvent etre utilises afin d'essayer d'obtenir des informations sur des secrets 

10 maniputes par la machine virtuelle Java. Ces secrets peuvent concerner aussi 
bien les donn^es confidentielles que le code Java lui-meme. 



L' invention a done plus particulierement pour but de supprimer ces 
inconvenients. 

15 

Elle propose, a cet effet, de rendre plus difficiles les attaques reposant sur des 
mesures physiques et/ou necessitant une synchronisation avec le code 
interprete en introduisant des variantes dans les temps d'execution des codes 
interprets et les empreintes physiques (par exemple, et de maniere non 
20 . exclusive, Emission electromagnetique, etc.) mesurables. 



Selon T invention, ce procede fait intervenir essentiellement deux types de 
variantes dans les temps d' execution des codes interpretes, de la maniere 
suivante : 

25 

- en provoquant a certains endroits d'un code interprete des derivations vers 
de nouvelles portions de code (qui n'appartiennent pas au code d'origine) 
destinees a compliquer la synchronisation et Tempreinte physique de 
Texdcution, ou 

30 - en proposant une pluralite de mises en oeuvre de certaines instructions, 
chacune r6clamant un temps d'execution diff6rent et/ou pr6sentant une 
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empreinte physique differente et fournissant un r6sultat identique, en faisant 
en sorte que deux executions de cette instruction au sein d'un meme code 
puissent etre r^alisees par deux mises en oeuvre differentes. 



5 Ainsi, en introduisant des distorsions dans les temps d'execution et en 
modifiant l'effet physique de l'execution, les deux types de variantes ci-dessus 
rendront plus difficile toute tentative de correlation entre les manifestations 
physiques observees d'un code interpr6te et ses fonctionnalites. 

10 Avantageusement, ce precede permettra de rendre le code apparemment 
execute different a chaque execution, et rendra done plus difficile la 
d6couverte du code reel de 1'application. 

Ce proced6 pourra faire intervenir : 
15 • pour la premiere variante : 

- deux modes d' introduction de "codes de derivation", 

- quatre modes de realisation de "codes de derivation", 
• pour la deuxieme variante : 

- deux modes d'introduction de "mises en ceuvre multiples" de 
20 certaines instructions, 

- trois modes de realisation de "codes alternatifs" a empreinte 
physique et duree variable. 

Concemant la premiere variante, ie premier mode d'introduction de "codes de 
25 derivation" consiste a introduire une (ou des) instruction(s) specifique(s), 
dite(s) "de derivation" a certains endroits particuliers du code. Cette 
introduction peut etre realisee soit manuellement, soit automatiquement lors de 
la generation de code. Dans le dernier cas, le generateur de code peut etre 
guide, pour produire ces instructions, par des annotations inserees par le 
30 programmeur dans le code source et permettant de designer des portions de 
code sensibles (par exemple, et de maniere non limitative, des procedures de 
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chiffrement ou de verification de droits d'acces). Uexecution d'une instruction 
de derivation par Tinterpr&eur provoque un branchement vers un code de 
derivation associe. Ce premier precede peut egalement etre ameiiore en 
attachant difiterents niveaux de s6curite aux instructions de derivation et en 
5 leur associant des codes de derivation d'autant plus complexes (ou defensifs 
vis k vis d'attaques de securite d6crites ci-dessus) que leur niveau de s6curite 
est 61eve. 

Concemant la premiere variante, le deuxieme mode d' introduction de "codes 
10 de derivation" consiste h introduire le code de derivation dans la mise en 
oeuvre de Tinterpreteur lui-meme: entre Texecution de deux instructions 
consecutives du code, Tinterpreteur execute le code de derivation, soit de 
maniere systematique, soit de maniere selective, soit de maniere aleatoire. II 
peut par exemple ex£cuter ce code seulement lors de Tappel de certaines 
15 methodes (typiquement de biblioth^ques, dites API "Application Program 
Interface") sensibles. 

L'avantage du premier mode est de permettre d'introduire les executions de 
code de derivation de maniere selective, ce qui conduit a une moindre 
20 penalisation en terme de temps d f ex6cution si le nombre de telles derivations 
est faible. II permet egalement la mise en oeuvre de politiques de securite dites 
"discretionnaires", c'est a dire k la discretion des applications. 

En revanche, le second mode sera plus avantageux si le nombre de derivations 
25 souhaitees est important car la mise en oeuvre du precede dans rinterpreteur 
lui-meme pourra alors etre optimisee. Par ailleurs, il permet la mise en oeuvre 
de politiques de securite dites "mandataires" ou les controles sont imposes de 
maniere uniforme a toutes les applications. 

30 Les deux precedents susdits modes d' introduction necessitent Tintroduction 
d'un code de derivation. L'invention propose quatre modes pour realiser ces 
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codes de derivation de manure k ce qu'ils introduisent des variantes dans les 
temps d'ex6cution et les empreintes physiques mesurables. 

Concemant la premiere variante, le premier mode de realisation de "codes de 
5 derivation" k empreinte physique et duree variable consiste k effectuer un 
calcul dit "superflu" dependant de donn6es connues k Tex6cution (qui peuvent 
done diffSrer k chaque execution). Ce calcul superflu doit etre sans effet sur le 
r6sultat final de l f ex6cution de Pinterpreteur. Un exemple simple de tel calcul 
est un test de parity d'une donnee dynamique (connue k Tex6cution) qui peut 
10 conduire soit a une action vide, soit a l'ajout d'un element d'une pile suivi de 
son retrait immediat. II est k noter que le nombre d'actions possibles n'est pas 
forcement limits a deux. Un nombre factions possible important conduira a 
une variability importante dans le temps d ! ex6cution et l'empreinte physique 
du code de derivation. 

15 

Le deuxieme mode de realisation de "codes de derivation" ameliore le premier 
mode en le dotant d'un tirage al6atoire d'une donhee supplemental lors de 
Tex6cution du calcul superflu, ladite donn6e supplemental etant utilisee dans 
le calcul effectue par le code de derivation (par exemple dans un test dudit 
20 code). Ce tirage aleatoire ajoute un nouvel element variable et rend encore 
moins previsible le temps d'execution et l'empreinte physique du code de 
derivation. 



Le troisieme mode de realisation de "codes de derivation" am61iore Tefficacite 
25 des deux precedents en rempla?ant le test permettant de decider de Taction 
suivante par un branchement dans un tableau dit d'indirection, e'est-a-dire 
contenant les adresses des actions possibles, a un indice calcuie a partir des 
Elements variables (donn£e dynamique et/ou resultat d'un tirage al6atoire). 

30 Le quatri&me mode de realisation de "codes de derivation" am£liore le premier 
mode (et par consequent les trois autres) en considerant un calcul superflu qui, 
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tout en restant sans effet sur le resultat final, pr6sente les caract6ristiques 
externes (empreinte physique) d'un calcul sensible particulier (par exemple 
chiflfrage ou dechiffrage) sans rapport avec le code effectif de Implication. Un 
tel calcul superflu permet de tromper un attaquant qui tenterait de deduire des 
5 secrets en mesurant l'effet physique de TexScution de l'application. Un tel 
proc6d6 peut etre qualifi6 de "leurre logiciel" puisqu'il a pour objet d'induire 
en erreur les attaquants en leur faisant croire k la presence dudit calcul sensible 
dans le code effectif de Tapplication. Ce mode peut etre realise simplement en 
mettant en oeuvre le calcul sensible en question sans retenir son resultat. 

10 

Concernant la deuxieme variante, le premier mode d'introduction de "mises en 
ceuvre multiples" de certaines instructions consiste a enrichir Tensemble des 
instructions reconnues par rinterpr6teur avec une plurality de mises en oeuvre 
pour une instruction donnee. Ces mises en oeuvre seront realisees de fa£on a 

15 avoir des empreintes physiques et des temps d'execution differents tout en 
produisant un resultat identique. N'importe laquelle de ces mises en oeuvre 
peut etre utilisee indifKremment dans le code. Cette utilisation peut etre 
effectuee soit manuellement, par programmation, soit automatiquement lors de 
la generation de code. Dans ce dernier cas, le g6nerateur de code peut etre 

20 guide, pour produire ces instructions, par des annotations inserees par le 
programmeur dans le code source et permettant de designer des portions de 
code sensibles (par exemple, et de maniSre non limitative, des procedures de 
chiffrement ou de verification de droits d'acces). Ce premier mode peut 
6galement etre amelior6 en attachant differents niveaux de s6curite aux mises 

25 en oeuvre ^instructions et en leur associant des mises en oeuvre d'autant plus 
complexes (ou defensives vis k vis d'attaques de s6curit£) que leur niveau de 
s6curite est elev6. 

Concernant la deuxi&me variante, le deuxieme mode d'introduction de "mises 
30 en ceuvre multiples" de certaines instructions consiste a inclure dans la mise en 
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oeuvre elle-meme de Tinstruction un branchement k une portion de code 
altematif qui d6terminera dynamiquement la mise en oeuvre k ex6cuter. 

L'avantage du premier mode est de minimiser le surcout en terme de temps 
5 d'ex6cution puisque le choix de la mise en oeuvre ^instruction a appliquer est 
d6termin6 prealablement k l'execution. II permet egalement la mise en oeuvre 
de politiques de securite dites "discretionnaires", c'est k dire a la discretion des 
applications. 

10 L'avantage du second mode est de compliquer encore les attaques n6cessitant 
une synchronisation avec le code puisque deux executions consecutives de la 
meme instruction (au meme emplacement dans le code) seront susceptibles de 
prendre des temps d'execution differents et d'offiir des empreintes physiques 
differentes. Par ailleurs, ce second mode permet la mise en oeuvre de 

15 politiques de securite dites "mandataires" ou les controles sont imposes de 
manidre vmiforme k toutes les applications. 

Les deux modes ne s'excluent pas mutuellement : une realisation peut inclure 
une multiplicite de mises en oeuvre pour une instruction donnee, certaines 
20 d'entre elles (ou toutes) etant mises en oeuvre par un branchement k une 
portion de code alternatif determinant dynamiquement la mise en oeuvre a 
executer. 

Le susdit deuxidme mode de la deuxieme variante necessite Tintroduction d'un 
25 code altematif associ6 a une instruction. L'invention propose trois modes pour 
r6aliser ce code altematif de maniere a ce qu'il introduise des mises en oeuvre 
differentes dans les temps d'execution et Tempreinte physique mesuree. 

Concernant la deuxieme variante, le premier mode de realisation de "codes 
30 alternatifs" a empreinte physique et dur6e variable consiste a proposer une 
pluralite de mises en oeuvre differentes de Tinstruction et de conditionner le 
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choix de la version ex6cutee k un test dynamique, c'est k dire dependant de 
donn6es connues k TexScution. Un exemple simple de tel calcul est un test de 
parit6 d f une donn6e dynamique (connue k Tex6cution). Un nombre de mises en 
oeuvre important conduira k une variability importante dans le temps 
5 d'execution et dans Tempreinte physique du code alternatif. 

Le deuxi&ne mode de realisation de "codes alternatifs" ameliore le premier 
mode en le dotant d'un tirage aleatoire d'une donnee qui est ensuite utilisee 
pour la realisation du test conduisant au choix dynamique de la version 
10 ex^cutee. Ce tirage al6atoire ajoute un nouvel element variable et rend encore 
moins previsibles le temps d'ex^cution et Tempreinte physique du code 
alternatif. 



Le troisieme mode de realisation de "codes alternatifs" ameliore Tefficacite 
15 des deux precedents en remplafant le test permettant de decider de la version 
choisie par un branchement dans un tableau d'indirection (contenant les 
adresses des versions disponibles) a un indice calcule k partir des Elements 
variables (donnee dynamique et/ou resultat d'xm tirage aleatoire). 



20 Ainsi, V introduction de variantes dans les temps d' execution des codes 
interpr£tes et done les empreintes physiques permet de rendre plus difficiles 
les attaques reposant sur les dites empreintes physiques, en faisant en sorte 
qu'une action codee dans 1* implementation de Tapplication puisse avoir des 
signatures electroniques differentes et se produisant a des temps d'execution 

25 variables. 



L'impl&nentation des susdits codes interpr6t6s sera effectu^e sur des modules 
d'interpretation de code logiciel comme des machines virtuelles de la famille 
JAVA, et sur des modules d' interpretation de code physique du type micro- 
30 controleur ou micro-processeur. 
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1. Proc6de de s6curisation des systemes informatiques comprenant au 
moins un module ^interpretation de code et des capacity m£moire de 

5 stockage du code interprets presentant des empreintes physiques mesurables, 
caracteris6 en ce que dans le but de rendre plus difficiles les attaques reposant 
sur des mesures physiques ou n6cessitant une synchronisation avec le susdit 
code interpr&e, il consiste k introduire des variantes d*ex6cution du code 
interprete, lesdites variantes ayant un effet sur les temps d' execution du code 

10 interprets ou ses empreintes physiques mesurables. 

2. Proc6de selon la revendication 1, 

caractdrise en ce qu'il comprend des derivations vers de nouvelles portions de 
code, dits "codes de derivation", qui n'appartiennent pas au code d'origine. 

15 

3. Proc6de selon la revendication 1, 

caract6rise en ce qu'il comprend une plurality de mises en ceuvre de certaines 
instructions, chacune reclamant un temps d'execution different ou presentant 
une empreinte physique differente tout en fournissant un r6sultat identique. 

20 

4. Precede selon la revendication 2, 

caracterise en ce qu'il comprend un premier mode d* introduction de "codes de 
derivation" consistant a introduire une (ou des) instruction(s) specifique(s) a 
certains endroits particuliers du code, soil manuellement soit automatiquement 
25 lors de la generation du susdit code. 

5. Proced6 selon la revendication 4, 

caracteris6 en ce que les instructions de derivation sont associees a des 
niveaux de s6curit6 qui correspondent k des degres de complexit6 de leur code 
30 de derivation, les plus complexes etant considers comme les plus d6fensifs 
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vis k vis d'attaques de s^curite necessitant une synchronisation avec le code ou 
une mesure de son empreinte physique. 

6. Procede selon la revendication 2, 
5 caract6ris6 en ce qu'il comprend un deuxi&ne mode d'introduction de "codes 
de derivation" consistant k introduire le code de derivation dans la mise en 
oeuvre de l f interpr6teur lui-meme. 



7. Procede selon la revendication 6, 
10 caracterise en ce que le code de derivation introduit dans la mise en ceuvre de 
rinterpr6teur est ex6cut6 soit de mantere systematique par l'interpr6teur, soit 
de maniere selective, soit de maniere ateatoire. 



8. Procede selon la revendication 2, 
15 caract&ise en ce qu'il comprend un premier mode de realisation de "codes de 
derivation" consistant a effectuer un calcul dit "superflu" dependant de 
donnees connues a 1' execution. 



9. Proc6de selon la revendication 2, 

20 caracterise en ce qu'il comprend un deuxieme mode de realisation de "codes 
de derivation" consistant k doter le susdit premier mode d'un tirage aleatoire 
d'une donnee suppl6mentaire lors de 1'execution du calcul superflu, ladite 
donnee suppl&nentaire 6tant utilisee dans le calcul effectue par le code de 
derivation. 

25 

10. Procedd selon la revendication 8, 

caracterise en ce que le susdit premier mode de realisation de "codes de 
derivation" est am&iore en attachant difffcrents niveaux de securite aux mises 
en oeuvre destructions et en leur associanf des mises en oeuvre d'autant plus 
30 complexes. 
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11. Precede selon la revendication 2, 

caracterise en ce qu'il comprend un troisieme mode de realisation de "codes de 
derivation" consistant k remplacer dans les susdits premier et deuxieme mode 
le test permettant de decider de Taction suivante par un branchement dans un 
5 tableau ^indirection contenant les adresses des actions possibles a un indice 
calculi a partir des elements variables (donn6e dynamique et/ou resultat d ! un 
tirage aieatoire). 

12. Proc6de selon la revendication 2, 

10 caracterise en ce qu'il comprend un quatrieme mode de realisation de "codes 
de derivation" consistant a effectuer un calcul superflu presentant les 
caracteristiques externes d'un calcul sensible particulier. 



15 caracterise en ce qu'il comprend un premier mode d'introduction d'une 
pluralite de mises en oeuvre de certaines instructions consistant a enrichir 
1'ensemble des instructions reconnues par 1'interpreteur avec une pluralite de 
mises en ceuvre pour une instruction donnee ; les susdites instructions sont 
effectuees soit manuellement, par programmation, soit automatiquement lors 

20 de la generation du code. 

14. Procede selon la revendication 3, 
caracterise en ce qu'il comprend un deuxieme mode d'introduction de la 
susdite pluralite de mises en oeuvre de certaines instructions consistant a 
25 inclure dans la mise en oeuvre elle-meme de rinstruction un branchement a 
une portion d'au moins un code alternatif k empreinte physique ou duree 
variable qui determine dynamiquement la mise en oeuvre a executer. 



13. Procede selon la revendication 3, 



15. Precede selon la revendication 14, 
30 caracterise en ce qu'il comprend un premier mode de realisation du susdit 
code alternatif consistant a proposer une pluralite de mises en oeuvre 
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differentes de l'instruction et en conditionnant le choix de la version ex6cut6e h 
un test dynamique, c'est a dire dependant de donnees connues a Texecution. 

16. Procede selon la revendication 14, 
5 caracterise en ce qu'il comprend un deuxieme mode de realisation du susdit 
code alternatif consistant a ameliorer le susdit premier mode de realisation de 
"codes alternatifs" en le dotant d'un tirage al6atoire pour la realisation du test 
conduisant au choix dynamique de la version ex6cutee. 

10 17. Procede selon la revendication 14, 

caracterise en ce qu'il comprend un troisieme mode de realisation du susdit 
code alternatif consistant k ameliorer les susdits premier et deuxieme modes 
de realisation de "codes alternatifs" consistant a remplacer le test permettant 
de decider de la version choisie par un branchement dans un tableau 

15 d'indirection contenant les adresses des versions disponibles k un indice 
calcuie a partir des elements variables. 

18. Precede selon la revendication 1, 

caracterise en ce qu'il est impiemente sur un module ^interpretation de code 
20 logiciel dit machine virtuelle. 

19. Precede selon la revendication 18, 

caracterise en ce que ladite machine virtuelle est une plateforme Java. 

25 20. Precede selon la revendication 1 , 

caracterise en ce qu'il est impiemente sur un module ^interpretation de code 
physique. 



21. Precede selon la revendication 1, 
30 caracterise en ce qu'il est impiemente sur un systeme embarque et sur un 
module d' interpretation du type micro-controleur ou micro-processeur. 



